…ctory

The held selector was discarded inside the data source factory by comparing
context instance identity, which only held while the factory was invoked for
every context change. Move the reset to the data manager's identify path,
keyed on the context canonical key, so a context change clears the basis
regardless of the active connection mode (including offline) and independent
of factory invocation timing. The factory no longer tracks the context.

The override test asserted only that a DataSource was produced, which holds
whether or not the override is honored. Assert that resolvedDefinition picks
the override for the overridden mode and the built-in otherwise. Translating a
definition's entries into concrete sources stays covered by the entry-factory
tests. Adds a visibleForTesting accessor and the meta dependency it needs.

Flutter 3.22.3 pins meta to 1.12.0 through its SDK dependency (via
connectivity_plus), so a ^1.16.0 floor broke workspace version solving on
that toolchain while passing on the newer one. visibleForTesting has been in
meta since well before 1.12.0.

…and selector

Replaces the derived PayloadEvent.basis flag with the explicit signals it
stood for. A cache load -- a full changeset with no selector -- is applied and
resolves a cached identify, but does not mark the source valid or satisfy a
wait-for-network identify. Network data carries a server selector and does
both. An intent-none, or being offline, resolves a wait-for-network identify
since no selector will arrive. This mirrors js-core's FDv2DataManagerBase
minimum-data-availability handling. The wire-level basis query parameter is
unaffected.

…ntext keys

Identify now unconditionally clears the held selector, matching js-core's
FDv2DataManagerBase (which resets the selector on every identify). The
previous context-key comparison split the "which context is the selector
for" invariant between the data manager (holding the key) and the data
system (holding the selector), with nothing keeping the two consistent. Mode
switches still keep the selector, since they reach the data source manager
directly rather than through the data manager.

The note described the method by contrast to the FDv1 verbs and to a
prematurely-valid bug that no longer exists, rather than the code as it is.

Drops the contrast with the removed context-instance inference and the stale
"reset on a context change" wording; the data manager clears the selector on
every identify.

It returns without completing when a wait-for-network identify has not yet
seen fresh data, so the name should reflect that it is conditional.

setValid was gated on the change set carrying a selector, but an intent-none
(the server confirming no changes) carries none -- so a healthy reconnect that
reported no changes left the status stuck at interrupted. Gate status (and the
wait-for-network identify) on whether the change set is server data -- a
selector-bearing payload or an intent-none -- rather than a cache load (a
selector-less full). Matches js-core and android, where any synchronizer
response, including no-change, restores valid. Adds a regression test.

Three linked changes that finish the FDv2 data system in common_client:

- Status: the manager marks the source valid on any applied change set while
  online (offline keeps its offline status). No selector inference -- a
  cache load and a no-change response both report valid, matching js-core.

- Initialization: the orchestrator, which knows the source tier, emits a
  single InitializedEvent (selector-bearing initializer, initializer
  exhaustion with data or in a cache-only system, or the first synchronizer
  change set). The manager resolves a wait-for-network identify on it; a
  cached identify resolves earlier on the first applied payload. Replaces the
  fragile type+selector inference, and an FDv1-fallback first response now
  completes a fresh identify.

- FDv1 fallback: a new FDv1 fallback synchronizer (an FDv1 poller whose
  responses translate to full, selector-less change sets tagged
  fdv1Fallback:false) is appended as the terminal, initially-blocked slot
  when a mode configures it. The orchestrator ignores a fallback directive
  once already on FDv1. The x-ld-fd-fallback detection was already present.

A fresh fallback synchronizer instance must not inherit a prior instance's
ETag, which would let it receive a 304 for a connection it never made and
keep stale data. The if-none-match header is per-requestor instance state.